No-Code Hack – Use Calculated Fields for Event Age Validation

This past weekend I was at Dynamics Power Saturday in Amsterdam an delivered a session I call “No-Code Hacks”. One of my hacks was to show how you can solve a requirement for age limit at event by only using customization, a requirement usually solved with JavaScript.

What is a Hack?

To start with I might need to explain the use of the word hack. About a month ago I recorded a chat with Scott Durow for his Power Platform Unpacked video series. He pointed out that the word hack has a negative ring to it in the world of developers. He was referring to the use of it as something you use as a ugly workaround for something you couldn’t solve in a sustainable way. And yes – that is a reasonable association.

I see it more as in the term of a “Life hack” – something to help you be creative in ways you wouldn’t usually be. So I went to the Urban Dictionary and found the definition I like a bit better:

A clever or elegant technical accomplishment, especially one with a playful or prankish bent. A clever routine in a computer program, especially one which uses tools for purposes other than those for which they were intended, might be considered a hack.

Now that’s more like it! These hacks I presented as a session, and write about, is really just meant to be inspirational ways to use configuration to solve requirements without using code. Whether you want to use these hacks in a solution or not is up to you, your situation and your views on technical debt (which is a completely different blog post). Now enough with the jibber jabber and let’s take a look at the actual hack!

The Requirement and it’s Challenges

To start with we have an Event and an Event Registration entity. The Event has, not very surprisingly, a start and an end time.

The requirement is about having a user friendly way to make sure that a contact that is not of age does not get registered as a participant to the Event.

First Challenge – Only Birthday on Contact

The only information OOB (Out Of the Box) that refers to how old a Contact is, is the birthday field, not the actual age it self. I need to somehow transform the birthday into a number, which leads me to challenge number two.

Second Challenge – DiffinYears and DiffinMonths

If I were to use Birthday on contact in a calculated field and either use the DiffinYears or DiffinMonths, it would not be precise enough. The reqirement is not that the participant should be of the right age that year or that month. It has to take the exact day into consideration. Okay – but what about DiffinDays? Which lead me in to challenge number three.

Third Challenge – Leap Years

Back in the days Julius Ceasar and his posse of astronomers decided to add an extra day ever fourth year to even out those extra hours it takes for the earth to fully revolve around the sun. Kind of reasonable – we don’t want to end up celebrating Christmas in the middle of the summer. But still – it kind of screws up calculating age in Dynamics. So I can’t use Diffindays divided by 365 days either. Thanks Julius.

The Salvation

But at least Julius Ceasar was consistent. A leap year every fourth year is something I can work with. So this is how I solved it.

I start with making sure that the Birthday field and the Events Start date have the same field behavior. If they don’t, you won’t be able to use Diffindays with these field.

I then create a calculated field on the Event Registration that calculates the age at the time of the event for the participant. I will have to use a Decimal number with ten decimals to make sure it’s precise enough. I will divide the Diffindays by 365.25 to take the leap year into consideration.

I will then create a real-time workflow that runs on Create of the Event Registration, compare the Age limit at the Event entity with the calculated field.

If the age limit is greater than the age at the time of the event I’ll cancel the workflow with a message telling the user that the participant is too young to be registered.

Obviously, this being a 10-decimal field I would not put it on the form for the user to see (because it’s ugly). But for your eyes only I’ll make an exception.

And that’s it! Now we’ve achieved a way to handle age limit at events. If you were to implement this you would need to consider if there is a chance that an events start date ever changes, and how that would effect already booked participants.


Interested in learning more hacks? Read about my most popular hack here – Get Fields From Related Records Using Actions

One thought on “No-Code Hack – Use Calculated Fields for Event Age Validation

Add yours

  1. The answer you are solving for is ”are they old enough to attend”. Yes or no. So you don’t really care what their specific age is on the date of the event. Another way to look at this is to take the event date and subtract the minimum age required (e.g. event date minus 18 years). This gives you the born before date you need to compare with the persons birth date. If the birth date is equal to or before the ”born before” date, they are old enough to attend. You can use Jason Lattimer’s DateTime Workflow Utilties to easily do the year date math in a workflow.
    https://github.com/jlattimer/CRM-DateTime-Workflow-Utilities

    BTW, you have a great blog. Thanks for all the posts!

    Like

Leave a comment

Blog at WordPress.com.

Up ↑